The Internet Protocol (IP) is widely used to communicate over the Internet, however this protocol is not secure. Consequently, third parties can potentially eavesdrop on transmitted packets, repeat transmitted packets or divert packets off the network and replace the diverted packets with locally created or forged packets.
IPsec is a standardised protocol suite for securing IP communications by encrypting and authenticating IP packets. Members of the IPsec protocol suite include the Encapsulating Security Payload (ESP) and the Authentication Header (AH) protocols. The act of applying a protocol to an IP packet is known as a “transformation”.
IPsec protocols typically use one or more cryptographic algorithms to provide the services offered by the protocol. In typical computing systems, a specialised module called the Network Processing Unit (NPU) deals with network issues such as packet routing and processing. Computationally intensive functions like encryption and compression generally cannot be performed by the NPU with adequate levels of performance, particularly if the NPU is implemented in software executing on a Central Processor Unit (CPU). A separate hardware module referred to as a Security Processor Unit (SPU) is often used to offload IPsec functionality from the NPU. The SPU typically provides hardware acceleration in order to achieve the required performance.
There are several common architectures used to integrate an SPU into a system. One architecture is referred to as the “Flow-Through” architecture 108 as shown in FIG. 1. This architecture 108 is often referred to as “Bump-In-The-Stack” or “Bump-In-The-Wire”, depending on the placement of the SPU. Traffic, made up of transmit packets (also referred to as Tx packets) on the transmit path (ie. in the direction of arrows 110-113) originates at an Application Layer 106, passes down as depicted by respective arrows 110, 111 and 112 through a Network Processor 104, a Security Processor 102, and finally via a Link Layer 100 to the network 420 (see FIG. 3) as depicted by an arrow 113. A similar, reversed traffic flow of receive packets (also referred to as Rx packets) occurs for a receive path, depicted by respective arrows 114-117. This architecture 108 is commonly used in security gateways, but is expensive due to increased speed and complexity required in the SPU 102. It is also difficult to make the SPU 102 an optional unit because the SPU 102 becomes an integral part of the system 108.
Another architecture 208 is the “Look-Aside” architecture shown in FIG. 2. This architecture is commonly found in host machines. In this case the SPU is often referred to as a “co-processor”, or an “offload engine”. For the transmit path, traffic originates in an Application Layer 206 and passes down, as shown by an arrow 210, to a Network Processor 204. The Network Processor 204 passes the traffic, according to an arrow 216, to a Security Processor 202 for security processing. The processed packet is forwarded from the Security Processor 202, as shown by an arrow 215, back to the Network Processor 204, which passes the traffic, as depicted by an arrow 211, to a Link Layer 200 and on, according to an arrow 212 to the network 420 (see FIG. 3). A similar, reversed traffic flow occurs for the receive path, depicted by respective arrows 213-214-217.
The look-aside architecture is more popular in hosts because it reduces the complexity of the SPU. Furthermore, the existing functionality of the NPU 204, such as buffering and fragmentation, can be reused in the IPsec implementation 208 of FIG. 2. In the architecture 208 it is relatively straightforward to make the SPU 202 a “pluggable” component. According to this approach, a low-cost device could omit the SPU 202, whereas a high-performance device would include the SPU 202.
Not all packets in an IPsec system are required to undergo transformation. Thus some packets require no IPsec processing at all, while other packets are required to undergo multiple transformations. IPsec has a method for establishing whether IPsec transformations are to be applied to a packet in a traffic stream. The rules that specify the behaviour of IPsec in regard to different packets are known as Security Policies (SPs). These SPs are created prior to processing network traffic, and are stored in a database known as a Security Policy Database (SPD).
IPsec requires that every packet be checked against the SPD, in a process known as Policy Checking. Not all traffic being communicated in an IPsec system need be secure. Typically, traffic comprises some traffic which must be secure, and other traffic where security is less of an issue or not important at all. There is thus typically a mixture of “secure” and “non-secure” traffic in a given traffic stream, often resulting from different, concurrent, higher layer sessions. The terms “secure” and “non-secure” refer respectively to packets that are to have IPsec processing applied to them, and those that do not.
The result of a policy check leads to one of three possible actions being applicable to the packet in question, namely “Apply”, “Bypass”, or “Discard”. The Apply rule means that the packet is to be transformed by IPsec, ie, it is a secure packet which is to be subjected to IPsec processing. The Bypass rule means that the packet is not to be transformed by IPsec, ie it is a non-secure packet. The Discard rule means the packet is to be dropped.
Because all packets must undergo policy checking, the rate at which the SPU is able to receive packets from the NPU, check packet policies, and apply protocol transformations typically has a significant influence on the performance of a system.
In the flow-through architecture, all packets, secure and non-secure, pass through the SPU. After receiving a packet the SPU performs a policy lookup. Packets determined to be secure can be held for transformation whereas non-secure packets can be forwarded without further processing. Sequential integration of policy lookup and transformation means non-secure packets are delayed by secure ones.
In the look-aside architecture, in one current arrangement, all packets are sent from the NPU 204 to the SPU 202 for policy checking and transformation. If a packet is determined to be in a non-secure category, then a notification is returned from the SPU 202 to the NPU 204 to forward the packet. In contrast, for traffic in a secure category, the NPU 204 must wait for a transformed packet to be returned to the NPU 204 from the SPU 202. This typically results in non-secure packets being delayed while the SPU 202 performs security processing of packets in secure categories.